A common use case we run into is producing the Kotlin proto library for a proto file A that depends on one or more proto files B. In such a case we would like to produce the Kotlin proto library for both A and B so we can use the Kotlin DSL to build both A and its nested fields of type B. However, the kt_jvm_proto_library macro does not have a way to express this quasi-dependency relationship. For example we have:

proto_library(
    name = "a_proto",
    srcs = ["a.proto"],
    deps = [":b_proto"],
)

proto_library(
    name = "b_proto",
    srcs = ["b.proto"],
)

kt_jvm_proto_library(
    name = "a_kt_proto",
    deps = [":a_proto"],
)

kt_jvm_proto_library(
    name = "b_kt_proto",
    deps = [":b_proto"],
)

We're not able to have users of the a_kt_proto target to automatically pull in b_kt_proto. We can work around this by addingb_proto directly as a dep of a_kt_proto so that both are compiled together. But this is less than ideal because, we may also have a c_proto that also depend on b_proto. If we put b_proto as a direct dependency of both a_kt_proto and c_kt_proto, the same file is compiled twice, and later on when we assemble a Jar combining a_kt_proto and c_kt_proto we get a conflict.

Of course a_kt_proto does not really depend on b_kt_proto, so everything still compiles and works. But users would expect to be able to use the Kotlin DSL to build all parts of the a.proto messages, including the parts that are from b.proto. And we do not want users to go hunt for all transitive dependencies of a.proto to find the corresponding kt_jvm_proto_library targets and assemble the dependency graph themselves. I think the runtime_deps concept appropriately captures the relationship between the two kt_jvm_proto_library targets, and we can accomplish the transitive dependency pulling by simply adding b_kt_proto as a runtime_dep of a_kt_proto. This PR adds rumtime_deps to the kt_jvm_proto_library to support this use case